Updated contribution guidelines with more explicit process for becomi… #723
Conversation
…ng a committer and publishing a release
|
|
||
| Releases are published manually from master by project Admins. | ||
|
|
||
| When a new release is published, it is first published as a release candidate. The candidate will be available for up to 1 week for testing from the community before |
There was a problem hiding this comment.
I like the idea of release candidates. That said, should we suggest a minimum time for non-critical (I.e. non-security related) releases to give the community time to consume it?
The way I’ve read this is that there is a maximum bake time of 1 week.
| # Community | ||
|
|
||
| While anyone is free to open pull requests against the project, Elide has two defined roles: | ||
| - *Committers* - Are the gatekeepers of the repository. They approve pull requests and have write access to merge against master or other mainline branches. Committers also help set the direction for the project by deciding on major enhancements or design changes. |
There was a problem hiding this comment.
Should we detail a more complete process for committers and admins in this doc? Perhaps a doc solely related to that may make more sense.
Anyway, what I’m expecting is something outlining the primary communication channels for committees/admins to stay on the same page with design and project movement.
I imagine much of this conversation to take place in a public place, but formalizing a location may make it easier for everyone to stay in sync.
|
|
||
| # Releases | ||
|
|
||
| Releases are published manually from master by project Admins. |
There was a problem hiding this comment.
We should also outline the release process in detail. Technically, how one would go about it, that is.
…ng a committer and publishing a release
I'm hoping for some healthy debate on this - so please consider this process a first pass.
Thanks.